which is necessary to properly read the element

I don't see why this is true. Grab the suffix of the input, beginning at the start of the value. The value itself contains everything you need to read the right amount, starting there. There's no particular reason to worry, ahead of time, where the value ends, so just pass the entire suffix to whatever needs to decode it.

If the value is dynamic it doesn't contain "everything you need". If the value is a dynamic array the length prefix will tell you how many elements are in the array but not the length of those elements. You need to read the last value of the array and get the length for that. And if that value is a dynamic array, you must do the same thing.

Even if the elements are dynamic, their heads are statically sized, and laid out first. You know how many there are from the length. And, if they are dynamic, they will have pointers to their dynamically sized tails.

But in the case of nested dynamic types you have to continuously extract the head and calculate length. If we knew the end of the tuple it'd be much easier to use that to extract/substring.

To be clear, the desired goal here is to be able to efficiently extract a single value from an encoded nested dynamic type.

If I understand correctly, this is not a great example because 0014 points to the end of the encoding, and that's not very useful here because it's just the length of the byte string.

Can you provide an example where the benefit of including this additional information is clearer?

Yeah this example was chosen to demonstrate the encoding rules, but it doesn't really show the rationale. Take a slightly more complex example:

[["Hello", "World"], [1, 2, 3]] encoded as (string[],uint8[])

0004 0018 0002 0004 000b 0005 48656c6c6f 0005 576f726c64 0003 01 02 03

To get the end of x[0][1] you will always need to check if x[0][1] is the last element of x[0]. If it's not, you just extract the next head but if it is you need to go up a level and get the head for x[1].

In this example, it exists but if there was further levels of nesting you would need to check if the parent element is the last element in it's parent and repeat until the next head is found. This means you need to spend opcodes checking the accessor against the prefix for every dynamic parent until you find the first parent tuple that has a dynamic element proceeding the accessed element.

In the context of TEAL compilers, the compiler has no way of knowing whether the accessed element is last or not without using up those opcodes, unless only literal array access is supported.

Alternatively, you use the length prefix to calculate the length of the accessed element, but if that element is a nested dynamic type then you run into similar complexity of needing to calculate the total length of the last element each level.

Why are you trying to get to the end of x[0][1]?

If your goal is to start decoding x[1], you already know where to start, because the head of x[1] is in a well defined spot (bytes 2-3 of the input), and that tells you that x[1] starts at by 0x18.

If you are not trying to reach x[1], then I suspect you are trying to substr out x[0] in order to give it to some decoding routine, so you'd like to know where it ends. But you don't have to do that. Just give that routine the entire suffix of the input, starting where head(x[0]) tells you to begin (byte 4).

You say it's hard "To get the end of x[0][1]" and I am saying that is not an operation you should need directly. If you are going down the dynamic path of x[0], you will find out where x[0][1] ends when you examine the head of x[0][1], combined with the length where head(x[0][1]) points. If you don't actually care about x[0][1] itself and are really just trying to get to the end of x[0], you know where x[1] begins.

The goal is to get the value of x[0][1] as efficiently as possible, so get the start of x[0][1], the end of x[0][1] and use substring3.

combined with the length where head(x[0][1])

Which is great when x[0][1] is of type T[] and T is static, but if T is dynamic then you need spend opcode budget to calculate the total length of x[0][1]. For every level of dynamic nested types in T, it consumes opcodes to calculate the total length. Having a value that points to the end of x[0][1] in the encoded data structure makes it trivial to get the end, rather than potentially having to calculate all of the lengths.

I explained why substr'ing out the value is not necessary.

I suspect you are trying to substr out x[0] in order to give it to some decoding routine, so you'd like to know where it ends. But you don't have to do that. Just give that routine the entire suffix of the input, starting where head(x[0]) tells you to begin (byte 4).

Surely it's even fewer opcodes to grab the suffix than to obtain the end (in any manner, whether by calculation or by pulling out the phantom length you want to add).